The linked PR specifies that the workaround is to explicitly list the default language in the fallbacks which is straightforward to do. Unless that doesn't work for some reason I would say that should be the path forward for users who want the fallbacks to default languages.

The suggested solution in the references PR is not viable for mongoid. You either need to set fallbacks for all locales in the world as a hash to make it work with mongoid. I18n.fallbacks needs to be a hash in the current mongoid implementation.

In svenfucks/i18n#415 the suggestion is to set I18n.fallbacks to a array. But you can't set fallbacks to a array when used with mongoid, current code in mongoid object[::I18n.fallbacks[locale].map(&:to_s).find{ |loc| object.has_key?(loc) }].

Another option would to create a custom fallback-class that takes care of the problems in mongoid.

Rails seems to solve it with not using version 1.1.0 of i18n, rails/rails#33566 until they have a solution for i18n new behavior. They seem to be adding this behavior to rails, rails/rails#33574.

When config.i18n.fallbacks = true Rails would set the fallback defaults to [] relying on I18n to add the default locale into the fallbacks. As I18n no longer does this, Rails will now explicitly set the fallback defaults to the current locale.

Maybe mongoid needs a to also handle arrays and booleans?

My current understanding of the situation is as follows:

1. Regardless of intentions, the i18n change appears to be a BC break for some users, and perhaps should not have been made in a minor version.

2. There are benefits to the new behavior, and there should be a way to use it when the application runs on i18n >= 1.1.

Mongoid does not directly depend on i18n. This dependency is obtained through activesupport, which currently depends on i18n < 2. Therefore, and taking point 2 above into account, pinning to i18n 1.0 is not something Mongoid should do.

Mongoid should support users who pin i18n to 1.0 or 1.1 within their application. I created https://jira.mongodb.org/browse/MONGOID-4614 to test both configurations.

In each configuration there should be tests for fallback to default locale and fallback to no translation/error. Based on my reading of the rails PRs mentioned I believe all possible permutations are achievable.

There should not be an automatic fallback to the default locale; it should be required to be listed. I propose to reject this PR.

The tests added in this PR can be valuable regardless to verify correct fallback behavior against both 1.0 and 1.1 of i18n.

I agree that Mongoid should refrain from changing i18n's behavior, and instead should allow the user to select either i18n 1.0 or 1.1 via application gemfile version specification.

https://jira.mongodb.org/browse/MONGOID-4662 for this PR.

I am ok to merge the tests only for this.

we had a problem that could have been solved if mongo took more action on this. fallbacks are totally broken with the latest i18n.

Right now the only ticket in the backlog that is related to i18n is https://jira.mongodb.org/browse/MONGOID-4662 which is adding tests to validate that Mongoid works with both 1.0 and 1.1+ versions of i18n, maintaining each version's behavior with respect to fallbacks. If you have a different issue please create a new ticket.

The tests and documentation for fallbacks with i18n 1.0 and 1.1+ are added in #4703.

You either need to set fallbacks for all locales in the world as a hash to make it work with mongoid.

@smgt Correct me if I'm wrong, but does this not apply to all libraries using i18n? https://github.com/ruby-i18n/i18n/wiki/Fallbacks shows the hash syntax for specifying fallbacks.

If so, it is out of scope for Mongoid to provide a different API for i18n.